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Definitions of Managed Objects for 
the Ethernet-like Interface Types 


Status of this Memo 


This RFC specifies an IAB standards track protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 
Distribution of this memo is unlimited. 


Abstract 
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in TCP/IP-based internets. 


In particular, it defines objects for managing ethernet-like objects. 
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1. The Network Management Framework 


The Internet-standard Network Management Framework consists of three 
components. They are: 


STD 16/RFC 1155 [3] which defines the SMI, the mechanisms used for 
describing and naming objects for the purpose of management. STD 
16/RFC 1212 [13] defines a more concise description mechanism, 
which is wholly consistent with the SMI. 
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RFC 1156 [4] which defines MIB-I, the core set of managed objects 
for the Internet suite of protocols. STD 17/RFC 1213 [6] defines 
MIB-II, an evolution of MIB-I based on implementation experience 
and new operational requirements. 


STD 15/RFC 1157 [5] which defines the SNMP, the protocol used for 
network access to managed objects. 


The Framework permits new objects to be defined for the purpose of 
experimentation and evaluation. 


2. Objects 
Managed objects are accessed via a virtual information store, termed 


the Management Information Base or MIB. Objects in the MIB are 
defined using the subset of Abstract Syntax Notation One (ASN.1) [7] 


defined in the SMI. In particular, each object has a name, a syntax, 
and an encoding. The name is an object identifier, an 
administratively assigned name, which specifies an object type. The 
object type together with an object instance serves to uniquely 
identify a specific instantiation of the object. For human 


convenience, we often use a textual string, termed the OBJECT 
DESCRIPTOR, to also refer to the object type. 


The syntax of an object type defines the abstract data structure 
corresponding to that object type. The ASN.1 language is used for 
this purpose. However, the SMI [3] purposely restricts the ASN.1 
constructs which may be used. These restrictions are explicitly made 
for simplicity. 


The encoding of an object type is simply how that object type is 
represented using the object type’s syntax. Implicitly tied to the 
notion of an object type’s syntax and encoding is how the object type 
is represented when being transmitted on the network. 


The SMI specifies the use of the basic encoding rules of ASN.1 [8], 
subject to the additional requirements imposed by the SNMP. 


2.1. Format of Definitions 
Section 4 contains contains the specification of all object types 
contained in this MIB module. The object types are defined using the 


conventions defined in the SMI, as amended by the extensions 
specified in [13]. 
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3- 


Overview 


Instances of these object types represent attributes of an interface 
to an ethernet-like communications medium. At present, ethernet-like 
media are identified by three values of the ifType object in the 
Internet-standard MIB: 


ethernet-csmacd (6) 
iso88023-csmacd (7) 
starLan (11) 


For these interfaces, the value of the ifSpecific variable in the 
MIB-II [6] has the OBJECT IDENTIFIER value: 


dot3 OBJECT IDENTIFER ::= { transmission 7 } 


The definitions presented here are based on the IEEE 802.3 Layer 
Management Specification [9], as originally interpreted by Frank 
Kastenholz of Interlan in [10]. Implementors of these MIB objects 
should note that the IEEE document explicitly describes (in the form 
of Pascal pseudocode) when, where, and how various MAC attributes are 
measured. The IEEE document also describes the effects of MAC 
actions that may be invoked by manipulating instances of the MIB 
objects defined here. 


To the extent that some of the attributes defined in [9] are 
represented by previously defined objects in the Internet- standard 
MIB or in the Generic Interface Extensions MIB [11], such attributes 
are not redundantly represented by objects defined in this memo. 
Among the attributes represented by objects defined in other memos 
are the number of octets transmitted or received on a particular 
interface, the number of frames transmitted or received ona 
particular interface, the promiscuous status of an interface, the MAC 
address of an interface, and multicast information associated with an 
interface. 


The relationship between an ethernet-like interface and an interface 
in the context of the Internet-standard MIB is one-to-one. As such, 
the value of an ifIndex object instance can be directly used to 
identify corresponding instances of the objects defined herein. 
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4. Definitions 


RFC1398-MIB DEFINITIONS ::= BEGIN 


IMPORTS 
Counter, Gauge 
FROM RFC1155-SMI 
transmission 
FROM RFC1213-MIB 
OBJECT-TYPE 
FROM RFC-1212; 


-- This MIB module uses the extended OBJECT-TYPE macro as 
-- defined in RFC-1212. 


—-- this is the MIB module for ethernet-like objects 


dot3 OBJECT IDENTIFIER ::= { transmission 7 } 
-—- { dot3 1 } is obsolete and has been deleted. 


4.1. The Ethernet-like Statistics Group 


—-- the Ethernet-like Statistics group 
—- Implementation of this group is mandatory 


dot3StatsTable OBJECT-TYPE 


SYNTAX SEQUENCE OF Dot3StatsEntry 
ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 


"Statistics for a collection of ethernet-like 
interfaces attached to a particular system." 
:= { dot3 2 } 


dot 3StatsEntry OBJECT-TYPE 


SYNTAX Dot3StatsEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 


"Statistics for a particular interface to an 
ethernet-like medium." 

INDEX { dot3StatsIndex } 

::= { dot3StatsTable 1 } 
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Dot3StatsEntry ::= SEQUENCE { 

dot 3StatsIndex 
INTEGER, 

dot 3StatsAlignmentErrors 
Counter, 

dot3StatsFCSErrors 
Counter, 

dot 3StatsSingleCollisionFrames 
Counter, 

dot 3StatsMultipleCollisionFrames 
Counter, 

dot3StatsSQETestErrors 
Counter, 

dot 3StatsDeferredTransmissions 
Counter, 

dot 3StatsLateCollisions 
Counter, 

dot 3StatsExcessiveCollisions 
Counter, 

dot3StatsInternalMacTransmitErrors 
Counter, 

dot 3StatsCarrierSenseErrors 
Counter, 

dot 3StatsFrameTooLongs 
Counter, 

dot3StatsInternalMacReceiveErrors 
Counter 


} 


dot3StatsIndex OBJECT-TYPE 


SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"An index value that uniquely identifies an 
interface to an ethernet-like medium. The 
interface identified by a particular value of 
this index is the same interface as identified 
by the same value of ifIndex." 

::= { dot3StatsEntry 1 } 


dot 3StatsAlignmentErrors OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"A count of frames received on a particular 
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interface that are not an integral number of 
octets in length and do not pass the FCS check. 


The count represented by an instance of this 
object is incremented when the alignmentError 
status is returned by the MAC service to the 
LLC (or other MAC user). Received frames for 
which multiple error conditions obtain are, 
according to the conventions of IEEE 802.3 
Layer Management, counted exclusively according 
to the error status presented to the LLC." 
REFERENCE 
"TEEE 802.3 Layer Management" 
::= { dot3StatsEntry 2 } 


dot3StatsFCSErrors OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"A count of frames received on a particular 
interface that are an integral number of octets 
in length but do not pass the FCS check. 


The count represented by an instance of this 
object is incremented when the frameCheckError 
status is returned by the MAC service to the 
LLC (or other MAC user). Received frames for 
which multiple error conditions obtain are, 
according to the conventions of IEEE 802.3 
Layer Management, counted exclusively according 
to the error status presented to the LLC." 
REFERENCE 
"IEEE 802.3 Layer Management" 
::= { dot3StatsEntry 3 } 


dot 3StatsSingleCollisionFrames OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"A count of successfully transmitted frames on 
a particular interface for which transmission 
is inhibited by exactly one collision. 


A frame that is counted by an instance of this 
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object is also counted by the corresponding 
instance of either the ifOutUcastPkts or 
ifOutNUcastPkts object and is not counted by 
the corresponding instance of the 

dot 3StatsMultipleCollisionFrames object." 


REFERENCE 
"TEEE 802.3 Layer Management" 
:= { dot3StatsEntry 4 } 


dot 3StatsMultipleCollisionFrames OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"A count of successfully transmitted frames on 
a particular interface for which transmission 
is inhibited by more than one collision. 


A frame that is counted by an instance of this 
object is also counted by the corresponding 
instance of either the ifOutUcastPkts or 
ifOutNUcastPkts object and is not counted by 
the corresponding instance of the 
dot 3StatsSingleCollisionFrames object." 
REFERENCE 
"IEEE 802.3 Layer Management" 
::= { dot3StatsEntry 5 } 


dot3StatsSQETestErrors OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"A count of times that the SQE TEST ERROR 
message is generated by the PLS sublayer for a 
particular interface. The SQE TEST ERROR 
message is defined in section 7.2.2.2.4 of 
ANSI/IEEE 802.3-1985 and its generation is 
described in section 7.2.4.6 of the same 
document." 

REFERENCE 
"ANSI/IEEE Std 802.3-1985 Carrier Sense 
Multiple Access with Collision Detection Access 
Method and Physical Layer Specifications" 

::= { dot3StatsEntry 6 } 
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dot3StatsDeferredTransmissions OBJECT-TYPE 


SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"A count of frames for which the first 
transmission attempt on a particular interface 
is delayed because the medium is busy. 
The count represented by an instance of this 
object does not include frames involved in 
collisions." 

REFERENCE 


"IEEE 802.3 Layer Management" 


:= { dot3StatsEntry 7 } 


dot3StatsLateCollisions OBJECT-TYPE 


SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The number of times that a collision is 
detected on a particular interface later than 
512 bit-times into the transmission of a 
packet. 
Five hundred and twelve bit-times corresponds 
to 51.2 microseconds on a 10 Mbit/s system. A 
(late) collision included in a count 
represented by an instance of this object is 
also considered as a (generic) collision for 
purposes of other collision-related 
statistics." 

REFERENCE 


"TEEE 802.3 Layer Management" 


:= { dot3StatsEntry 8 } 


dot 3StatsExcessiveCollisions OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"A count of frames for which transmission ona 
particular interface fails due to excessive 
collisions." 
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REFERENCE 
"TEEE 802.3 Layer Management" 
::= { dot3StatsEntry 9 } 


OBJECT-TYPE 

SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"A count of frames for which transmission on a 
particular interface fails due to an internal 
MAC sublayer transmit error. A frame is only 
counted by an instance of this object if it is 
not counted by the corresponding instance of 
either the dot3StatsLateCollisions object, the 
dot 3StatsExcessiveCollisions object, or the 
dot3StatsCarrierSenseErrors object. 


The precise meaning of the count represented by 
an instance of this object is implementation- 
specific. In particular, an instance of this 
object may represent a count of transmission 
errors on a particular interface that are not 
otherwise counted." 

REFERENCE 
"IEEE 802.3 Layer Management" 

::= { dot3StatsEntry 10 } 


OBJECT-TYPE 


SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The number of times that the carrier sense 
condition was lost or never asserted when 
attempting to transmit a frame on a particular 
interface. 
The count represented by an instance of this 
object is incremented at most once per 
transmission attempt, even if the carrier sense 
condition fluctuates during a transmission 
attempt." 

REFERENCE 


"IEEE 802.3 Layer Management" 
::= { dot3StatsEntry 11 } 
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{ dot3StatsEntry 12 } is not assigned 


OBJECT-TYPE 
SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 
"A count of frames received on a particular 
interface that exceed the maximum permitted 


frame size. 


The count represented by an instance of this 
object is incremented when the frameTooLong 
status is returned by the MAC service to the 
LLC (or other MAC user). Received frames for 
which multiple error conditions obtain are, 
according to the conventions of IEEE 802.3 
Layer Management, counted exclusively according 
to the error status presented to the LLC." 


REFERENCE 
"IEEE 802.3 Layer Management" 
:= { dot3StatsEntry 13 } 


{ dot3StatsEntry 14 } is not assigned 


{ dot3StatsEntry 15 } is not assigned 


OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"A count of frames for which reception ona 
particular interface fails due to an internal 
MAC sublayer receive error. A frame is only 
counted by an instance of this object if it is 
not counted by the corresponding instance of 
either the dot3StatsFrameTooLongs object, the 
dot3StatsAlignmentErrors object, or the 
dot3StatsFCSErrors object. 


The precise meaning of the count represented by 
an instance of this object is implementation- 
specific. In particular, an instance of this 
object may represent a count of receive errors 
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on a particular interface that are not 
otherwise counted." 

REFERENCE 
"IEEE 802.3 Layer Management" 

::= { dot3StatsEntry 16 } 


4.2. The Ethernet-like Collision Statistics Group 


-- the Ethernet-like Collision Statistics group 


—- Implementation of this group is optional; it is appropriate 
-- for all systems which have the necessary metering 


dot3CollTable OBJECT-TYPE 


SYNTAX SEQUENCE OF Dot3CollEntry 
ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 


"A collection of collision histograms for a 
particular set of interfaces." 
:= { dot3 5 } 


dot 3CollEntry OBJECT-TYPE 


SYNTAX Dot 3CollEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 


"A cell in the histogram of per-frame 
collisions for a particular interface. An 
instance of this object represents the 
frequency of individual MAC frames for which 
the transmission (successful or otherwise) ona 
particular interface is accompanied by a 
particular number of media collisions." 

INDEX { dot3CollIndex, dot3CollCount } 

::= { dot3CollTable 1 } 


Dot 3CollEntry ::= SEQUENCE { 
dot 3ColliIndex 
INTEGER, 
dot3CollCount 
INTEGER, 
dot 3CollFrequencies 
Counter 
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dot 3CollIndex OBJECT-TYPE 


SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"The index value that uniquely identifies the 
interface to which a particular collision 
histogram cell pertains. The interface 
identified by a particular value of this index 
is the same interface as identified by the same 
value of ifIndex." 

:= { dot3CollEntry 1 } 


dot3CollCount OBJECT-TYPE 


SYNTAX INTEGER (1..16) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"The number of per-frame media collisions for 
which a particular collision histogram cell 
represents the frequency on a particular 
interface." 

::= { dot3CollEntry 2 } 


dot 3CollFrequencies OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"A count of individual MAC frames for which the 
transmission (successful or otherwise) ona 
particular interface is accompanied by a 
particular number of media collisions." 

::= { dot3CollEntry 3 } 


4.3. 802.3 Tests 


==. 802.3 Tests 


—- The ifExtnsTestTable defined in RFC 1229 provides a common 
-—- means for a manager to test any interface corresponding to 


Kastenholz [Page 12] 


RFC 1398 


Ethernet-Like MIB January 1993 


a value of ifIndex. 


At this time, one well known test (testFullDuplexLoopBack) is 
defined in RFC 1229. For ethernet-like interfaces, this test 
configures the MAC chip and executes an internal loopback 

test of memory and the MAC chip logic. This loopback test can 
only be executed if the interface is offline. Once the test 
has completed, the MAC chip should be reinitialized for network 
operation, but it should remain offline. 


If an error occurs during a test, the object ifExtnsTestResult 
(defined in RFC 1229) will be set to failed(7). The following 
two OBJECT IDENTIFIERs may be used to provided more 
information as values for the object ifExtnsTestCode in 

RFC 1229: 


dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } 


-- couldn’t initialize MAC chip for test 
dot 3ErrorInitError OBJECT IDENTIFIER ::= { dot3Errors 1 } 


—- expected data not received (or not 
-—- received correctly) in loopback test 
dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 } 


-—- Tests 


-—- TDR Test 


-—- Another test, specific to ethernet-like interfaces with the 
-—- exception of 10BaseT and 10BaseF, is Time-domain Reflectometry 


(TDR). 


—- The TDR value may be useful in determining the approximate 


distance 


—- to a cable fault. It is advisable to repeat this test to 


check for 


—- a consistent resulting TDR value, to verify that there is a 


fault. 
dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } 
dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 } 


—— A TDR test returns as its result the time interval, measured 


— in 10 MHz ticks or 100 nsec units, between the start of 


-—- TDR test transmission and the subsequent detection of a 

-- collision or deassertion of carrier. On successful completion 
-- of a TDR test, the appropriate instance of ifExtnsTestResult 
-- contains the OBJECT IDENTIFIER of the MIB object which 

-- contains the value of this time interval. 
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4.4. 802.3 Hardware Chipsets 
-—- 802.3 Hardware Chipsets 
—- The object ifExtnsChipSet is provided in RFC 1229 to identify 
-—- the MAC hardware used to communcate on an interface. The 
-- following hardware chipsets are provided for 802.3: 
dot 3ChipSets OBJECT IDENTIFIER = { dot3 8 } 
dot 3ChipSetAMD OBJECT IDENTIFIER = { dot3ChipSets 1 } 
dot 3ChipSetAMD7990 OBJECT IDENTIFIER = { dot3ChipSetAMD 1 } 
dot 3ChipSetAMD79900 OBJECT IDENTIFIER = { dot3ChipSetAMD 2 } 
dot 3ChipSetIntel OBJECT IDENTIFIER = { dot3ChipSets 2 } 
dot 3ChipSetIntel82586 OBJECT IDENTIFIER = { dot3ChipSetIntel 1 } 
dot 3ChipSetIntel82596 OBJECT IDENTIFIER = { dot3ChipSetIntel 2 } 
dot 3ChipSetSeeq OBJECT IDENTIFIER = { dot3ChipSets 3 } 
dot 3ChipSetSeeq8003 OBJECT IDENTIFIER = { dot3ChipSetSeeq 1 } 
dot 3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 } 
dot 3ChipSetNational8390 OBJECT IDENTIFIER ::= 
{ dot3ChipSetNational 1 } 
dot 3ChipSetNationalSonic OBJECT IDENTIFIER ::= 
{ dot3ChipSetNational 2 } 
dot 3ChipSetFujitsu OBJECT IDENTIFIER = { dot3ChipSets 5 } 
dot 3ChipSetFujitsu86950 OBJECT IDENTIFIER ::= 
{ dot3ChipSetFujitsu 1 } 
dot 3ChipSetFujitsu86960 OBJECT IDENTIFIER ::= 


individual enterprises 


{ d 


For those chipsets not represented above, 
assignment is required in other documentation, 
within that part of the registration tree delegated to 
(see RFC 1155). 


ot3ChipSetFujitsu 2 } 


OBJECT IDENTIFIER 
e.g., assignment 


END 
5. Change Log 
(1) Replace old "Historical Perspective" boilerplate with the 
new "The Network Management Framework" boilerplate. 
(2) Remove the "slime text". 
(3) Updated the reference to the Interface Extensions mib to 
reflect its new RFC status. 
Kastenholz 


[Page 14] 


RFC 1398 Ethernet-Like MIB January 1993 


(4) Change the status of the memo section to hold the new 
suggested text. 


(5) References in ASN.1 comments were changed from the [#] 
form to name the actual document being referred to. These 
references are now meaningful when the ASN.1 is read 
outside of the RFC. 


(6) The IMPORTS section of the ASN.1 has been updated to 
reflect that the OBJECT-TYPE macro is imported from RFC- 
P2122: 


(7) The the Generic Ethernet-like group, containing 
dot3Index, dot3InitializeMac, dot3MacSubLayerStatus, 
dot 3MulticastReceiveStatus, dot3TxEnabled, and 
dot3TestTdrValue has been deprecated as a result of the 
implementation experience presented at the San Diego IETF 
meeting. 


(8) dot3StatsInRangeLengthErrors and 
dot 3StatsOutOfRangeLengthFields have been deprecated as a 
result of the implementation experience presented at the 
San Diego IETF meeting. 


(9) Update the acknowledgements section to reflect this 
document’s history, etc. 


(10) REFERENCE clauses have been added to all of the MIB 
objects which are being retained. 


12 August 1992 
(1) Removed all deprecated objects. 


(2) Rephrased the description of the TDR test OID to reflect 
the fact that dot3TestTdrValue is no more. 
ifExtnsTestResult still points to the object containing 
the result, the text simply does not refer to 
dot3TestTdrValue. I could have deleted the Test, but the 
OID should then remain reserved. I figured that it would 
be just as easy to rephrase the definition of the test. 


13 august 1992 


(1) Add fuji. 86960 
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